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Chapteii Introduction 
1 .1 Envisioned Home Network Development 

At the beginning of the 21^ century, households are faced with a multitude of issues, including 
global environmental issues, such as protecting the ozone laya* and reducing CO2 output to prevent 
global warming, and the aging of society. Notably, there aie calls for both industry and ordinary 
households to reduce CO2 output by lowering energy consumption. Other issues include rising health 
care costs and the growing need for nursing care as society grows older. 

At the same time, rapid advances in data and communications infiastmcture, in the form of 
high-speed, high-bandwidth communications and multimedia capabilities, are making it easier than 
ever for households to connect to the outside world via such rnecKa as cable W a^^ 

Homes in (he 21^ centuiy will need to be linked to. society to provide safe, pleasant, and 
environmentally sound services, and this revolution is expected to create a host of business 
opportunities. Urgently needed are the creation of a communications infrastmcture linking homes and 
society and enabling the realization of such services and the development and proliferation of an 
in-home communicatioris infiastmcture! to this end, a variety of technologies are being studied in 
' Japan and abroad. 

The in-home communications infiastmcture, or *1iome network," will need to provide fiist, 
high-bandwidth transmission of data and iiriages. At the same time, it will have to incorporate a 
relatively low-speed/bandwidth^cost network that is compatible with conventional home qjphances 
and equipment 

This network will enable the interconnection and systematic operation of a wide assortment of 
home appliances and controllers from different manufacturers. In addition to being more 
ene^-efiicient, homes featuring such networks will be safer, more comfortable, more user-friendly, 
and more environmentaUy sound and wiU be ready to meet the chaUenges of enei^ 
aging ofsociety, and home nursing care. 

for example, to satisfy the growing need for energy conservation and load balancing, eflScient 
energy utilization can be achieved through such features as user-friendly display of household energy 
use, autoniatic shut-off of appliances not in use, and autornatic shiflm 

expensive times of the day. This will provide fine-tuned energy savings and load-shifting 
automatically and create a new level of home comfort and convenience. 

In addition, declining birth rates and the consequent grayirig of society are expected to increase the 
need to provide safety and security to households with seniors and to reduce the burden of home 
nursing care and health rnanagement. to meet this need, home networks could put occupants at ease . 
and help them monitor their health by allowing easy retrieval of useful information in daily life. They 
a)idd also be easily liriked to toe systems of hospita^^ . 

.M 
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Further, the use of conttpls fine-tuned for common situations in daily life would enable the 
convenient, eflScient operation of household ^pliances and equipment. When the house is 
unoccupied, for example, the system would switch to monitoring mode, automatically locking the 
doors and windows, turning off the air conditioner, and turning out the lights. On cold winter nights, 
the system would turn on the outdoor lights, close the curtains, and warm cold rooms in preparation 
for the occupants' return. 
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1.2 ECHONET Development Objectives 

ECHONET (Energy Conservation and Homecare Network) was created to realize the kind of 
home network system described iri the preceding pages, along wifli necessary related systems. 

In the past, individual Japanese manufacturers have developed and marketed their own home 
automation systems based on the HBS (Home Bus System) standard Such systems, however, have 
failed to acMeve significant penetration in ordiiiaiy households. 

This can be attributed to several factors. First, no currently available appKcation systems oflFer 
. acceptable cost performance. Also, the difficulty of developing network-cpnpatible devices, which 
are much more complex than ordinary household ^pliances, has represented a heavy burden for - 
developers, to these factors can be added the difficulty of connecting and maintaining networks of 
network-compatible devices, making their use in ordinary homes difficult, and the need for special 
wiring, which limited isuch systems to new homes. 

Utilizing the results and experience of HBS development, ECHONET will provide the base 
technology for the development of next-generation home networic systems capabte 
the aforementioried.changes in the social infrastmcture, global environmental issues, and the aging of 
society. 

' ECHONET will develop: 1) a commuriications protocol for a reUable, low-cost home^^ 
requires rio new wiring and can be installed iri existing homes; 2) rnultivendor-compatible home 
network equijMnent; 3) system models for use by individual vendors to facilitate development of 
application systems; 4) communications middleware and development support tools to mitigate the 
burden of developing equipment; and 5) application service-compatible middleware to facilitate - 
development of applications required for energy conservation. 

By reducing the burden of system and device development and facilitating equipment 
interconnection, we hope to promote the creation of attractive, low-cost application systems that more 
eflFectively utilize household appUarices and devices. 
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1.3 ECHONET Aims 

The ECHONET specifications were drawn \sp in response to the requirements of various groips, ranging 
fi-om end users to product developeis and system installers, They focus on the objectives listed below. 

(1) Etata transmission without special wiring 

Transmission mefliods that do not require rewiring, and thus can be used in existing homes, such as ordinary 
power lines, wireless, and infiiared, are used as the main transniission media. By taking advantage of the unique 
characteristics of these media, users can select the transmission media best suited to device and system 
characteristics. They can also develop systems without concern for the media via which the device will be 
connected This assures great flexibility when ^proaching varying system needs in the fliture. 

(2) Easy developnientofmultivendor home systems 

Home networks will become worthy of tiieir name only when they make possible the tnouble-fiiee connection 
and operation of devices fiom various rhanufacturers. System models and specifications assure not only a 
common communications protocol between devices but also interconnectability at the system level. Thus, users 
can choose and install the device that best meets their needs fiom a range of ECHONET-compliant products 
fium various vendors. 

(3) Response to long lifetime and home system proliferation 

Home network systems are characterized by the long lifetime (renewal cycle) of the ^pliances and devices 
conprising the network and continuous changes in system configuration driven by changes in family make-up, 
nioves to new homes, and the addition of new devices or services. ; Widespread adoption of home network 
systems will also require a wide variety of connection meftiods, which will enable the incorporation of 
non-ECHONET-conpliant devices, and an architecture that fecilitates replacqmerit of equipment and devices. 

(4) Environment facititating development of ECHOl^T-compUaiit d^ 

ECHONET stipulates the environment and interface conditions for the development of components that will 
support fiiture development of major application systems. These components include hardware and software 
cornx)nents to be shared by all devices (such as communications modules and software to be incorporated in 
each device) and required for energy managanenL This enables flexible development of ECHONET-related 
components and applications, fi:eeing vendors to concentrate on the development of more fiindamental features 
and perfonnance. The end result will be flie developnient of system products that are more usefid for users. 

' (5) Easy system instalMon arid device instaUatipn,rq)lacement, and m^^^ 

Phig-and-piay fiuictionality makes it possible for anyone to set ip the system and iiistall, replace, and move 
system devices. . 

(6) Connectability and coexistence with other (AVQ systems 

ECHONET specifies a scheme to enable low-cost connections with systems based on local standards in 
expectation of global adoption and connections with in-home image and data processing systems. 

1-4 
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1.4 Envisioned Applications 

As noted above, the first aim of EGHONET is to develop and promote adoption of a home network 
system using the electric appliances and equipment found in ordinaiy homes. 

Fig. 1.1 shows envisioned applications for ECHONET. As shown in the diagram, ECHONET is 
designed for use with application systems containing the same devices and functions found in 
ordinary homes, including single-family dwellings, duplexes, apartment buildings, dormitories, and 
condominiums for senior citizens. 

Also targeted are equiprnent systems for small office buildings and stores that are similar in terms of 
scale and system environment (cost, system lifetime, functions, wiring restrictions, etc.) and that have 
yet to make substantial use of building management systerns or other faciHty ni^ 
Ix)WK:ost, easy-to-use subnetwork systaiK can be appli^ 
systenis for stnaU buildings, or floor-by-floor systerris in larger stmctures. 

Systems designed primarily to monitor and control equipinoit are characterized by severe 
constraints on memory and other resources but have a low voliime fiequency of data exchange 
between individual devices. ECHONET can provide the foundation for a low-speed/capacity/cost 
network that meets these requirements. 
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Fig. 1.1 Envisioned applications for ECHONET 
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1.5 ECHONET Characteristics 

In accordance with the objectives described above, ECHONET was developed to provide the 
following characteristics: 

(1) Support for various transmission media without rewiring 

To facilitate adoption, installation, and use of the system in existing homes, ECHONET siq>ports a 
wide range of transmission media, including both new and existing technologies, with a focus on 
those requiring no special wiring, such as ordinary power lines, wireless, and infrared. For power lines, 
which many expect to serve as core of the home network system, a reliable, high-speed power line 
communications protocol was developed that is compliant with Japanese power line regulations and 
noise environment. The ECHONET architecture also enables seamless handling of devices connected 
using various media, thereby Ik^ilitating systerns developrnent. 

(2) Object-oriented modeling of system configuration 

The specifications were kept clear and consistent by the use of object-oriented modeling of 
individual devices, interface methods (when using system functions), and the division of fimctioris 
between devices. This guarantees interconnectivity fiTom commiinications between individual devices 
to the systap level and assures an integrated multivendor systen^ 

(3) Open networic architecture 

To create devices that are system- and networic-compliant, network connection fimctions were 
layered (in the communications layer stmcture), with specifications provided for the fimctions of each 
kyer and for the interJayer interface reqii^^ 

vendors to fiieely develop and comrnercialize. ECHONET-relaled hardware con5X)nents, soflware 
components, arid development erivironments. This ■ includes development and distribution of 

transmission media-level communications module components, development and distribution of 
ECHONETKX)mpliant communications drivers and middleware, and creation of development 
environments that facilitate development of these software con:5X^ 

(4) API (AppUcation Programming Interface) . 

Developing network-compatible fimctions has always represented a heavy burden for developers of 
device control soflware and ^plication software (e.g., controllers and control units). In response, 
ECHONET will develop shared APIs that access the object models described above. By utilizing 
communication middleware that implements these APIs, application softvvare developers will be able 
to develop netwoik-compUant devices without having to concern ttiemselves with cornmunication 
protocols and transmission media differences. 

(5) Plug-and-playfimctionality 

Under ECHONET, systems will configure themselves automatically when a device is connected to 
the network, eliminating the need for system setup and installation by users, whether ordinary 
consumers or trained technicians. This is what is ineant by plug-and-play fimctionality. ECHONET will 
provide a system enabling autpinatic aUocation of conmiunicati^ 

. ■. ■ • 1-6. 
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device-identifying data, automatic recognition of device functions, and support for automatic setup of 
ppetating data, such as device instaUation location and inter-^^ 

(6) Service middleware 

for each specific service plication, the system will specify as s^ce middleware the shared, basic 
fiinctions required by that ^licatioa By utilizing service middleware and the relevant APIs, 
. application software developers will find it easy to develop home system applications. ECHONET 
also defines service objects to enable access to these service middleware functions via the netwoik. By 
utilizing the service objects of individual nodes, systems designers will be able to configure systems 
more efficiently. 
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Chapter2 Definition of System Configuration 
2.1 ECHONET System Arcliitecture 

This section will specify the ECHONET system make-n) system architecture. Figure 2. 1 shows 
the ECHONET system architecture. 

ECHONET incorporates into a system groups of devices with the same management of properties, 
security, and so on Therefore, the largest arca that ECHONET can manage is rcferrcd to as a domain. A 
domain will be specified as the range of controlled resources (home equipment, appKances and 
consumer electronic^ sensors; controllers, remote controls, etc.) present within the network r^ige 
determined by ECHONET. In other words, a domain is. a network range within which the transmission 
of data is logically guaranteed. A system is defined as that which performs communication and linked 
operations between devices and the controllers that monitor/control/operate them and between devices 
' themselves. A system lies within one domain and does not extend over a number of domains. A 
domain includes one or more systems. Thus, the same device or controller can exist in more than one 
system. Wh^ connecting a system to another system lying outside the domain, an ECHONET 
gateway is used as an interface. . 




Fig, 2.1 System architecture 
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Concrete examples will be provided to help explain domain scope and the configuration of 
application systems. In reality, of course, each system designer will design systems in accordance with 
system size and the aforementioned criteria and will not be limited by these specifications. 

Single-family dwellings: Entire stmcture 



Dual-family dwellings: 
Apartment buildings; 

Stores: 
Buildings: 



Entire stmcture, or by family 

By individual units and shared areas. Depending on its purpose, an 
application system may be applied to an entire building. 
Entire stmcture 

Entire stmcture, floor-by-floor, by type of facility to be managed, etc. 
depending on building size and type of management. 



As shown in Fig. 2.2, ECHONET Nodes (a node is defined as any device or controller connected 
to the network) in a system are able to exchange data freely and without distinction between 
controllers and devices and between devices themselves. Also, the system is defined without regard to 
lower-layer protocols, such as the network transmission media to be described later. The Fig. shows 
two q)plication systems, A and B, within a domain; the devices within this domain may belong to one 
or both of these systems. In the example shown in the Fig., each system defines the controllers 
inplementing the applications that manage (control, monitor, eto.) the devices connected to the system 
Each device can communicate not only with the controllers in its system but also with other devices. 

ECHONET specifies network architecture and systan management based on these principles. It 
does not put constraints on product systmi architecture. 



External | 
systems J 



Sy^em 




Fig. 2.2 Domain scope and application system configuration (example) 
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2.2 ECHONET Network Configuration 

To enable the construction of optimal systems utilizing the unique characteristics of various 
transmission media, ECHONET allows use of numerous transmission media and protocols. The 
ECHONET network configuration model for the main transmission media are shown in Fig. 2.3. As 
described in the Fig., connections outside the domain are made using ECHONET gateways (GW). 
Connections between different protocols (i.e., different transmission media) witiiin tiie same domain are 
made using ECHONET routers. The network whose boundaries are describesd by a single ECHONET 
router is called a subnet The ins^on of an ECHONET router enables the creation of different subnets 
with the same protocol. A domain's network configuration can be represented as a collection of subnets. 
Li other words, a domain is the part of the configured networic, including ECHONET routers, within 
which in-house data is communicated 

In a subnet, each node- s identifia (Node ID) is defined and used as an ECH 
fitoction (defined as an ECHONET Node) identifier unique within that subnet. Each subnet has its own 
unique subnet identifier (Net ID). An ECHONET address is defined as the subnet identifier plus the 
node identifier, and this pair becomes the ECHONET Node identifier unique within that domain. 

ECHONET routers use the ECHONET address, which is unique for each ECHONET Node, to 
connect different transmission media seamlessly with respect to the system. This eliminates the need for 
an upper-layer level ..(i,e., ECHONET system architecture definitions) to recognize differences in 
tiansmission media, as noted above. 




Fig. 2.3 ECHONET network configuration model 
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2.3 ECHONET Component Devices 

This section describes the ECHONET component devices defined in the network configuration and 
system architecture above. 

(1) ECHONET Node 

A communications node based on the ECHONET specification. Within ECHONET, this refers to 
ECHONET communications functions identified uniquely by an ECHONET address. This tmn 
makes no distinctions between the q>pIication functions of the node and is lised when describing the 
node's finictions as a single commuiiications tennin^ 

(2) ECHONET device 

An ECHONET Node with ECHONET-compatible communications interface and 
system-compliant fiinctions; riiay include home equipment, home appliances and consumer electronics, 
and building or store facilities (e.g., lighting, air conditioning, refiigeration, electrical power facilities, 
ordinary white goods, sensors, arid actuators). Also, an ECHONET Node acting as a controller, such as 
central control devices that nionitor, control, or operate these nodes, or control units (e.g., remote control 
units). 

(3) Device adapter 

An adapter designed to connect devices without commimications interfaces for 
. ECHONET-specified trananission media to ECHONET during the early stages of adoption. Interfece 
. specifications for devices and ECHONET device adapters will be based on the ECHONET device 
adq^ter interface specification to be provided separately. . 

(4) ECHONET gateway : 

Connects ECHONET doriiains to external systems, including otiier ECHONET domains. A riumber 
of ECHONET gateways may exist within the same domain, deperiding on differences in the external . 
systems to be connected to. 

(5) ECHONET router 

An ECHONET Node designed to connect an ECHONET subnet to another ECHONET subnet It 
can be used to connect subnets with different lower-layer protocols (i.e., in cases of different 
transmission media or different media protocols) or to partition a . single protocol into a number of 
subnets. 
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2.4 Connections to External Networks and Systems 



In homes, buildings, and stores, a variety of extemal networks exist, including outside networks for 
connecting to hospital systems, etc., and those designed to transmit image and other data on other 
in-home networks. ECHONET, which is positioned as a field network, views these networks as being 
outside the domain and connects to them at the application level via ECHONET gateways. When 
directly sending and receiving messages to and fi*om extemal systems, protocol conversion is 
perfonned at the application level. Henceforth, networks outside the domain will be referred to as 
extemal networks. Extemal applications will be referred to as extemal systems. 

. In the ECHONET specifications for connection with extemal systems, the concept of defining object 
models for each specific application based on user or vendor needs is being studied fiiom the stanc^int 
of how to present the in-liouse network to extemal systems. These object models are called gateway 
service objects, and the middleware that implements their functions is referred to as gateway service 
middleware. These definitions have two objectives: . 

• When developing external systems, to enable use of the same model for ECHONET adoption 
- system, indepCTident of in-house vendors. 

'When developing in-house systenis, to enable development of ^ 
of external systenis handling the same services. . . 

Based on this concept, users can freely choose and arrange extemal or in-house system vendors. Also, 
ECHONET does not specily a unique doinain identifier. It is the extemal system that seeks to idaitify 
specific ECHONET domains, and flierefpre extemal systems are responsible for adopting methods to 
identify each dornain. 



External network , 



In-house network 



Extemal 
system 



Etfiemet, PHS, Dofa, 
ISDN, etc 



AVC system net vork 
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Gateway. 



extemal system medium 


AVC system medium 
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Fig. 2.4 Connection to xtemal systems 
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Chapters ECHONET Communication Layer Configuration 
3.1 Overview of ECHONET Communication Layer Configuration 

The ECHONET device communication layer can be broadly divided into three layers: Application 
Software, Communication Middleware, and Lower-layer Communication Software. The ECHONET 
specification will provide specifications for Communication Middleware and for Lower-layer. 
Communication Software. 

■ Application Software 

Application Software can be broadly divided into software that provides remote control of 
devices connected to the ^stem and software that realizes the hardware fimctiohs of such 
individual devices as air conditioners and refiigerators. 

■ ECHONET Communication Middleware 

ECHONET Communication Middleware is provided between the Application Software and 
the Lower-layer Communication Software and processes communication in accordance with the 
ECHONET communication protocol In other words, it realizes the principal features of 
ECHONET 

■ Lower-layer Communication Software 

Lower-layer Communication Software handles the communication protocol processing 
unique to each Transmission Medium, such as power line, wireless, and infeared. It is primarily 
responsible for processing communications corresponding to Layers 1 and 2 in the OSI reference 
model. Lower-layer Communication Software is defined for each supported communication 
protocol. At present Version 2.10 of the ECHONET specification defines Lower-layer 
. Comrnvinication Software for the following protocols: power line communication protocol, 
wireless comrnvinication protocol, ihfiared conirniinication protocol QxDA Control), extended 
HBS protocol, and LonTaik protocol 

Fig. 3. 1 shows a conceptual view of the ECHONET comrnunication layer configuration. 
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Application Software 




Fig. 3-1 Overview of ECHONET communication layer configuration 



3-2 Communication Layer Elements 

Fig. 3.2 shows the overall communication layer configuration fiarther divided into a number of 
processing blocks. 

ECHONET Communication Middleware consists of the ECHONET Communication Processing 
Block, the Protocol Diflference Absorption Processing Block, and Device Objects. Fig. 3.2 also shows 
the following communication layer configuration block interfaces: Basic APIs (^plication 
Programming Interfaces), Service APIs, Common Lower-layer Comrnunication Interface, and 
Individual Lower-layer Communication Interfeces. Finally, Service Middleware, which acts as a 
. shaxed Ubraiy to assist ^pUcation software processiiig, is presented as Se^ 

Of the processing block$ and processing block interfeces shown in Fig. 3.2, ECHONET specifies 
the shaded portions. 
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Fig. 3.2 ECHONET communication layer configuration 

3.2.1 Service Middleware 

As systems becomes more conplex and applications undertake more sophisticated processing, the . 
burden of developing appKcation software is greatly reduced by APIs, which provide common 
processes in the form, for example, of libraries. If a certain application is indicated, many more 
specialized processes can also be shared Service Middleware is the software that defines the shared 
, and basic pr(x:esses for a given appUcation and pnDvides the AP 
the application software. Further, ECHONET defines Service Objects as objects that enable use of 
these functions and settings by die network Service Middleware includes linked functions that can be 
applied to a variety of applications, scheduling fimctions, gateway fimctions (which establish 
connections with external networks), and functions designed for a specific application, such as home 
EMS (energy management system) ^plications, automatic electric and gas meter-reading 
applications, arid device rriaintenance applications. ECHONET will provide specifications for Service 
Mddlewaie going forwanl while extending the >^ety of av 
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3.2.2 ECHONET Communicatioh Processing Block 

The ECHONET Cornmunication Processing Block is responsible for processing the 
communication protocols needed to facilitate processing when application software is remotely 
controlling or monitoring a device in an equipment system; for storing the data needed to process 
communication protocols; and for managing device condition and other data. In other words, this 
block performs communication processing for accessing objects, such as the Device Objects of other 
devices. ECHONET specifies this communication protocol, of the data stored by this block, the data 
and access procedures that are disclosed to other devices are expressed as objects and specified as 
ECHONET object defiintions. Also specified are ranting processing and add 

3.2.3 Protocol DifFerence Absorption Processing Block 

The purpose of this block is to integrate networks consisting of numerous Lower-layer 
Communication Protocols and Transmission Media, such as power line, wireless, Lx)nTalk, and 
. infiared, and to present them as a single network. When aiming towards a system configuration that 
enables selection of Transmission Media, such as power line or wireless, depending upon the 
application, or that enables joint use of such media, .the need to consida- conplex network 
configurations and diiferences in address and message size for each Ti^^ 

tremendous burden during development work. ECHONET Communication Middleware presents 
such systerhs to applications as a single network. This fecilitates the development of qjplication 
software, wWch need not take into accomt complex network configuration^ 

ECHONET specifies address conversion methods, communication conversion methods, and 
message splitting and assembly methods performed in the Protocol Diflference Absorption Processing 
Block. 

3-2-4 Device Object 

The Device Object.is a logical model of the data stored by white goods and other equipment, such 
as sensors, air conditioners, and refiigerators, or of the control items which can be operated remotely. It 
provides an integrated interface format for remote control. Because the Device Object is specified 
separately for each type of device, simftar devices fi:om dife 

to (he same class, can be remotely controlled using the same operating sequence. Specifically, the data 
and control properties for each device will be specified as Device Object object properties, and the 
method of inaiiipulating them (settings and reference) wiU al^ 

Device Objects are defined using the HK (House Keeping) commands specified in JEM-1439. 

While JEM-1439 focuses mainly on household devices, ECHONET will also specify devices for 
small buildings and stores, 

3.2.5 Transmission Medium and Lower-Layer Communication Software 

ECHONET will specify communication protocol for power line, low-power wireless, infi-ared, 
LonTalk, and other transmission media. In the case of LonTalk and infi:ared (IrDA Control), existing 
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protocx)ls will be used, but ECHONET will specify how these protocols are to be incorporated (lc., 
which communication functions are to be used in what way). Lower-layer Communication Software 
processes the communication protocols unique to each Transmission Medium; primarily, this 
processing corresponds to Layers 1 and 2 of the OSI reference model Currently, Version 2.10 of the 
ECHONET specification defines the following Lower-layer Communication Software protocols: 
power line communication, low-power wireless communication, IrDA (infiared) control, extended 
HBS (twisted-pair cable), and Ix)nTalk (low-power wireless). 

3.2.6 API 

AppUcation sofhvare uses APIs to access other de\dces arid to access 
Communication Middleware of the Self-device. By specifying APIs, ECHONET aims to improve the 
portability of application software. / 

As shown in Fig. 32, there me two types of APIs: Basic API md Serviw 

(1) Basic API 

Basic APIs are designed to let ^plication software utilize basic ECHONET functions, and in 
general only these APIs need to be used. Basic APIs mainly submit processing requests for the 
management of ECHONET communications (start, stop, etc.) and for ECHONET communication 
transmission and reception fimctions. They are . called when accessing a remote device (and 
particularly when accessing Device Objects stored in a remote device). 

Basic APIs are also used by application software that remotely controls other devices, primarily in 
controllers, etc., and by device control applications which perform Self-device hardware control in air 
conditioners j refiigemtprs, serisors, arid so oa The ECHONET specificati 
APIs in both situations. 

(2) Service API 

. Service APIs are an interface enabling application software to use Service Middleware fimctions. 

Note also that Service Middleware uses Basic APIs when utilizing ECHONET Communication 
Middleware fimctions during internal processing. 
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3.2.7 Common Lower-Layer Communication Interface 

This interfece enables aU types of Ix)wer-kyer 
Corrimunication Middleware as having common specifications. It is used when using the Lower-layer 
Communication Software functions in a format in which Lower-layer Communication Software 
differences have been absoAed by the Protocol Difference Absorption Prcxxssing Block, 

The purpose for specifying this interface is to enable quick application of the ECHONET 
specifications to new Lower-layer Communication Software and to prevent impact on other 
component elements. These objectives are achieved by using a Common Lower-layer 
Communication Interfece to specify the interfece to be protected when modeling ECHONET 
Communication Middleware processing , and incorporating new Lower-layer Communication 
Software in the ECHONET specifications. 

3.2.8 Individual Lower-Layer Corrimunication Interface 

This is an interface between the Lower-layer Communication Software and the Protocol DiflFerence 
Absorption Processing block of the Commiinication Middleware. 

The purpose for specifying tiiis interface is to clarify the usage of communication protocols and 
Lower-layer Communication Software and to enable the development of devices tiiat can be 
interconnected, .regardless of manufacturer, using this specification and based on ECHONET 
standards. This includes cases in which the Lower-layer Communication Software communication 
protocol uses existing non-ECHONET standards (e.g., IrDA Control) or. in which off-the-shelf 
Lower-kyer Cbmmurucation Software (e.g., LonWorks 
• used; 
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Chapter4 Connection of Devices to ECHONET Networks 
4A Implementation of ECl-IONET Standard in Devices 

The decision of which part of the ECHONET specifications to use in a product will depend on its 
positioning in the communication layer and is left to the user. However, by using the same procedure 
for communications between devices, it is possible for devices to exchange data. Interconnectivity 
betwem devices is also needed to prevent an adverse impact on the processing of other devices. 

ECHONET aUows connection to the ECHONET network via ECHONET device adapters. To 
achieve device interconnectivity, the division of functions between ECHONET device adapters and 
the devices themselves must be clearly stated 

This section wiU explain the various types of ECHONET d 
as weU as the methcKb available for connecting devices to an ECHONET net^^ 

4.2 ECHONET Device Types 

ECHONET defines and specifies two types of ECHONET devices based on the content of the . 
supported ECHONET Communication Middleware. ECHONET device developers will need to 
select one of the two types and design their devices in accordance with specifications for the 
ECHONET communication layer configuration block (see Table 4.1) to be implemented in the 
device. 

(1) FuU ECHONET device 

(2) Flex ECHONET device 

(1) Full ECHONET device (Full_Device) 

A Full ECHONET device has a communication interface specified by ECHONET, such as power 
line communication, and can connect to an ECHONET system on a stand-^ 

(2) Rex ECHONET device (Flex_Device) 

A Flex ECHONET device ihcoiporates appKcation software and ECHONET Commvinication 
Middleware (ECHONET Communication Processing Block), which stands above the Common 
Lower-layer Communication Literface, and connects to an ECHONET system using a device ad^ter, 
wMch processes communication below the Common Ix)wer4ayer Commu^ 

Table 4. 1 shows the relationship between the ECHONET commiinication layer configuration block 
and die two types of devices described above. 
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Table 4.1 ECHQNET communications layer configuration block and ECHONET device types 





FulLDevice 


Flex_Device 


Application Software 


' O 


o 


Service Middleware 






Device Object 


O 


o 


ECHONET Communication Processing Block 


O 


o 


Protocol Di£bence Absoiption Processing Block 


O 




Lower-layer Communication Software 


O 




Adapter Communication Software 




o 



Note: O- required, — : not specified 

4.3 Adapters for Connection to ECHONET Networks 

A Flex ECHONET device is connected to an ECHONET network using a device ad^ter. A Fidl 
ECHONET device can connect to the network on a stand-alone basis, but a device adapter becomes 
necessary when the network transmission medium is not siq^ported by the device. In some cases, 
existing devices without an ECHONET communication interface can also connect to an ECHONET 
network using a dedicated device ad^ter. In this way, device adapters vary with the type of device to 
be connected. Two types of device ad^ters can be connected to Full and Flex ECHONET devices, 
and these are described below. Note that ECHONET cuirehtiy specifies only the first type of adapter 
(ECHONET device ad^ter). 

(1) ECHONET device adapter 

(2) Communication conversion device adapter , • 

(1) ECHONET device adapts 

Connecting a Flex ECHONET device with an ECHONET device adapter enables connection to an 
ECHONET system through &e addition of Ix)wer4ayer Comm^ 

(2) Communication conversion device adapter 

Connecting a Full ECHONET device with a device adapter enables connection to an ECHONET ^ 
system using a different I^wer-laya: Conmnuiiication p 

Table 4.2 shows the relationship between the ECHONET communication layer configuration block 
and the two ECHONET device adapter types. 
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Table 4.2 ECHONET communications layer configuration block and ECHONET device adapter types 





Transmission 
medium addition 
device adapter 


Comiinniications 
conversion device adapter 


Application Software 






Service Middewate 






Device Object 






ECHONET Communication Processing Block 






Protocol Diflerence Absorption Processing Block 


o ■ 


O 


Lower-layer Communication Software 


O 


O 


Adapter Comniunication Software 


O 





Note: O: required, — not specified 



4.4 Connection formats 

The format for connecting a device to an ECHONET network varies with the type of device. There 
are four forrnats, as shown below (see Fig. 4. 1). 

Format 1 : Direct cormection of a Full ECMONET device to the netwoik 
Format 2 : Connection of a Flex ECHONET device to the network using a device ad^ter 
Format 3: Connection of a Full ECHONET device to the network using a device ad^ter 
. Format 4: Connection ofan existing device to the networic using 

Of the connedion formats shown in Fig. 4,1, ECHONET currently specifies only the device 
ad^ter in Format 2. 
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format 1 : Direct connection of Full ECHONET device 



fbrniat 2: Connection of Flex ECHONET device 



Full ECHONET 

device 



Corrmurucadons 



ECHONET 
network 



Transmission medium 
addition adapter 



CJorrmmicalions 




ECHONET 
network 



ECHONET device adapter 
interface 



fomiat 3: Connection of Full ECHONET device 
via device adapter " 



ComrnLinicatians 
cxjnvcision device 



ECHONET 
network 



Full ECHONET 

device 



Cnrimunicaticns 



ECHONET 
network 



, format 4: Connection of existing devices 



%)ecial adapter to 
existing device 



Comrnunications 



ECHONET 
netwoik 



Existing device 



Proprietaiy 
netwoik. 



Fig. 4.1 Device adapter and device combinations 



The "existing device" shown in format 4 above would have a proprietary comniunications interface 
that is not specified by ECHONET (e.g., a one way infrared communication interfece) and would 
connect to an ECHONET system via an adapter with ECHONET communication functions. 
ECHONET does not specify an adapter designed to work witii existing device. 
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Chapters Structure of ECHONET Specifications and Intended Readership 
5.1 Structure of Specifications 

The ECHONET specifications are stmctured into the Volumes shown below. 

Parti ECHONET Overview 

ECHONET objectives, characteristics, overall architecture, definition of basic tenninology, 
and ECHONET device types. 

Part n ECHONET Communication Middleware Specifications 

Specifications for message format, communication address, protocol processing. Device 
Object definition, staitiq) sequence,.routing processing, etc., in the ECHONET Communication 
Middleware. 

Part in ECHONET Transmissiori Medium and Lower-Layer Communication Software 
Specifications 

O^mmunication protocol specifications for Lower-layer Communication Software, primarily 
from the viewpoint of Layers I and 2. 

PartIV ECHONET Basic APISpecifications 

Basic API specifications, which serve as iriterface specifications for the development of 
ECHONET-based application software. - . 

Part V ECHONET Common Lower-Layer Communication Interface Specifications 

Specifications for tiie communication interface, which is positioned betweeri the Protocol 
Difference Absorption Processing Block arid the ECHONET Communication Processing Block 
of the Communication Middleware. 

Part VI ECHONET Individual l^wer-l^yer Commmiication Interface Specifi 

Specifications for the Individual Lower-layer Communication Interface, which serves as the 
interface with ECHONET Communication Middleware for each Lower-layer Communication 
protocol. 

Part Vn ECHONET Communication Device Specifications 

Specifications for the device adapter interface and hardware specificatioris for when a devi^ 
viewed as communications device hardware. 

PartVm ECHONET Service Middleware Specifications 

Processing content and Service Object definition specifications for individual ECHONET 
Service Middleware. 

Part DC ECHONET Gateway Specifications 
. 5 1 
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Software specifications jfor ECHONET gateway as ECHONET Service Middleware, 

PartX ECHONET System Design Guidelines 

Gmdelines to be used in designing an ECHONET systeni fioni stanc^ 
design, operation, and maintenance. 

5.2 Intended Readership 

These specifications were designed to be read by developers of ECHONET devices, device 
adapters. Lower-layer Communication protocols, application software, and Service Middleware and 
by system developers and managers. Following is a suggestion of the Parts that readers in each group 
should focus on. 

(1) ECHONET device developers 

ECHONET device developers should read all Volumes, but particularly inportant are the sections 
regarding the ECHONET communications layer configuration components being supervised by tiie 
developer (including surrounding interfaces). 

(2) Device adapter developers 

Readas in this group should focus on Part VH ECHONET Communication Device Specifications 
and also read the following Volumes: Part 11 ECHONET Communication Middleware Specifications, 
Part ni ECHONET Transmission Medium and Lower-Layer Communication Software Specifications, 
Part V ECHONET Common Lower-Layer Communication Interface Specifications, and VI 
ECHONET Individual I^wer-lMyer Communication Interface SpeciJ^ 

(3) Ix)wer4ayerConimunication protocol developers 

Members of this group should read the following Volumes: Part II ECHONET Communication 
Middleware Specifications (especially the section on the Protocol Difference Absorption Processing 
Block), Part III ECHONET Transmission Medium and Lower-Layer Communication Software 
Specifications, Part V ECHONET Common Lower-Layer Communication Interface Specifications, 
and Part VI ECHONET Individual Lower-Layer Communication Interface Specifications, 

(4) Application software developers 

Readers in this group should focus on Part IV ECHONET Basic API Specifications and refer to 
Part n ECHONET Communication Middleware Specifications for an undostanding of protocol 
behavior and control items for devices to be controlled using APIs. Also, developers of 
controller-based system applications should read PartX ECHONET System Design Guidelines. 
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(5) Service Middleware developers 

Readers in this group should focus on Part JV ECHONET Basic API Specifications and also refer 
to Part Vin ECHONET Sendee Middleware Specificatiom for ihe 
: format described therein They should also read Part II ECHONET Communication Middleware 
Specifications for an understanding of protocol behavior and control items for devices to be controlled 
using APIs. 

(6) System developers and managers 

Members of this group should first read Part X ECHONET System Design Guidelines and then 
refer to Part II ECHONET Communication Middleware Specifications for an understanding of 
protocol behavior and control items for devices to be controlled using APIs. They should also read 
Part Vn ECHONET Communication Device Specifications and Part IV ECHONET Basic API 
Specifications. - . . . 

5.3 Vei^ion numbering system 

Since Version 1.01 of the ECHONET specification, the following numbering system has been used. 
FoUowing is a desqiption of the system using as an e;^^ 



« SDeciflcation Version no. 
• (space) 

^ Appendix management number 



i^i9 Release^a 



Starts from a for each Version 



ex Ver.2.l0 Release a 
-»Ver.2.10 Release b 
-»Ver.2. 11 Release a 



• (space) 

Minor changes 
Starts from 0 for each Version no. 



"^Official version no, (major additions or 
revisions) 
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